The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
gitnexus	Ready	Preview, Comment	May 20, 2026 6:15pm

Verification (issue #1684 acceptance criteria)

Verified locally on branch copilot/fix-analyze-hangs-on-root (614f3803) in worktree GitNexus-pr1693-worktree.

Automated checks

emitTsScopeCaptures perf (checker.ts, ~3.0 MB)

• 3073 ms for ~66k match groups (was >7 min before parent-walk fix per investigation)

Integration repro (raised limits + pathological file)

Mini repo with src/compiler/checker.ts + tests/cases/fourslash/reallyLargeFile.ts:

$env:GITNEXUS_MAX_FILE_SIZE = "32768"
$env:GITNEXUS_WORKER_SUB_BATCH_TIMEOUT_MS = "90000"
node dist/cli/index.js analyze <mini-repo> --force --index-only --skip-git `
  --max-file-size 32768 --worker-timeout 90 --name verify-pr-1693

Acceptance criteria mapping

• Raised-limit analyze completes in bounded time or skips pathological files with clear log — skip path confirmed
• reallyLargeFile.ts does not block entire chunk via sequential fallback — confirmed (unit test + integration log)
• compiler/checker.ts indexed under raised limits without worker timeout — confirmed in mini repro
• README documents TypeScript indexing expectations — not in this PR (follow-up)

Not run (scope / time)

Full microsoft/TypeScript repo root (~39k files) end-to-end — expected to take hours even with fix; prior hang was specifically sequential fallback re-parsing reallyLargeFile.ts indefinitely.

Verdict: Fix addresses the blocking failure mode from #1684; safe to merge from a verification standpoint (pending CI).

CI Report

✅ All checks passed

Pipeline Status

Test Results

✅ All 9356 tests passed

Code Coverage

Tests

_{📋 View full run · Generated by CI}

Claude finished @magyargergo's task in 7m 51s —— View job

Production-Readiness Review — PR #1693

1. Review Bar for This PR

• A pathological file (reallyLargeFile.ts) must not cause unbounded analyze time through any worker retry, split, or fallback path.
• Worker crashes, timeouts, and protocol violations must be bounded, attributed, and observable via logs/stats.
• Quarantine must be session-scoped, path-stable, and must not cause partial chunk results to enter the parse cache.
• WorkerPool.dispatch is documented as non-reentrant; parseChunkConcurrency must only overlap file I/O, never concurrent dispatch.
• IPC wire format must be mutually agreed between worker-pool.ts and parse-worker.ts; transferred buffers must not be pool-backed.
• TypeScript capture parent-walk must preserve exact semantic output for the anchor types it touches.
• Tests must cover real worker lifecycle paths; mock-only tests for lifecycle/IPC changes are not sufficient.
• Docs and benchmark scaffolds must not present TBD values as evidence.
• No hidden bidi/Unicode controls in executable code or tests.

2. Current PR State

3. Branch Hygiene Assessment

Classification: merge-from-main commit present, but rebase/split would be strongly preferred.

The PR is causally connected to #1684: the worker-hang fix required IPC changes, quarantine semantics, circuit breaker, respawn, TypeScript capture optimization, and CLI option threading — these are all interlocking and not cleanly separable. However the diff is ~6500 LOC across 34 files, includes benchmark scaffolding, a new bench/ doc directory, README updates, and CLI wiki changes. The branch has 42 commits including merge-from-main commits and a terminal merge at the head. The diff is reviewable but dense, and CI signal for the oldest commits is stale. A rebase/squash onto current main with squashed logical groups would make the final diff cleaner and reduce noise from intermediate states.

The merge-commit-heavy topology does not introduce unrelated files. The scope expansion (IPC repack, transfer-list, chunk prefetching) is causally necessary: the original hang was partly caused by IPC overhead and main-thread extraction blocking worker throughput. All changed domains are within the ingestion pipeline.

4. Understanding of the Change

Worker Pool (worker-pool.ts): Adds auto-respawn on crash/exit (bounded by maxRespawnsPerSlot), per-slot consecutive failure circuit breaker, session-scoped quarantine (quarantine.ts), authoritative starting-file in-flight tracking with fallback heuristic, per-job cumulative timeout budget, initial ready handshake gate, slot-generation guards on event handlers, getStats() observability, and getQuarantinedPaths() snapshot. Zero-copy transfer-list dispatch (buildDispatchMessage) moves file content out of JSON via TextEncoder.encode + ArrayBuffer transfer. Pool size default changed to cores-1 capped at 16 with os.availableParallelism().

IPC (protocol.ts, parse-worker.ts): Binary frame protocol (1-byte tag + 4-byte LE length + JSON body). parse-worker.ts handles both the framed Uint8Array shape and a hybrid {envelope, contents} shape where file content is zero-copy transferred. Both worker and pool decode the same contract.

Quarantine/Cache (parse-impl.ts): Cache writes suppressed for any chunk that contains a quarantined file. Pool quarantine snapshot checked per-chunk after dispatch. Next run gets a fresh miss and reattempts against a new pool.

Pipeline concurrency (parse-impl.ts): parseChunkConcurrency prefetches file contents up to N chunks ahead; dispatch itself stays serial. Extraction (imports, heritage, calls) deferred to a single end-of-loop pass so workers stay busy between chunk dispatches.

CLI/env (analyze.ts, index.ts): --workers <n> threaded through AnalyzeOptions → PipelineOptions without process.env mutation. Env snapshot/restore for ANALYZE_CLI_ENV_KEYS on each analyzeCommand invocation. --workers 0 correctly disables the pool via workerPoolSize !== 0 check.

TypeScript captures (captures.ts): findNodeAtRange (root DFS per match) replaced by findSelfOrAncestorOfType[s] (parent walk from capture node). Falls back to findNodeAtRange if ancestor walk returns null. Dedicated groupedNodes parallel map tracks raw SyntaxNode references for the walk.

5. Findings

F1 — MINOR | typescript-captures-anchor.test.ts:28 | findMatch helper is declared but never called

Evidence: CodeQL correctly flagged findMatch at line 28. Reading the file confirms it is defined but has zero call sites. countMatchesTsx (line 33) IS called on line 88. The findMatch function was likely an early draft that survived cleanup.

Risk: Dead code, no production impact.

Fix: Remove findMatch or call it in a test that uses its return value. Fix this →

Blocks merge: No.

F2 — MEDIUM | bench/parse-throughput.md:92-106 | Benchmark doc explicitly says "TBD — fill in before merging"

Evidence: The doc itself states:

Status: scaffold — fill in before merging the PR #1693 follow-up.

And:

Regenerate this file before merging any PR that touches the ingestion pipeline.

The table has _TBD_ for all worker-pool rows. The methodology is sound and the harness is documented, but the doc is shipped as-is in a state it explicitly describes as not merge-ready. A reader landing on this file after merge would see TBD data and assume the benchmark was never run.

Risk: Misleading operator documentation. DoD §2.4 states "if user-visible behavior [...] change, the relevant docs [...] are updated in the same change."

Fix: Either fill in the measurement rows with real numbers before merging, or retitle the doc clearly as "scaffold / future work" and remove the self-contradictory "fill in before merging" note. Fix this →

Blocks merge: Maybe — if the DoD "docs updated in the same change" bar is enforced strictly. Non-blocking if the maintainer accepts the scaffold-only state.

F3 — LOW | worker-pool.ts:234 | WorkerPoolDispatchError.fallbackExcludePaths is a misleading name after sequential fallback removal

Evidence: Commit be1f65c removed the sequential-parser fallback. WorkerPoolDispatchError.fallbackExcludePaths still exists and is still populated with quarantine snapshots. The name implies a sequential fallback path that no longer exists. Current callers (parsing-processor.ts) catch WorkerPoolDispatchError but the sequential fallback call they used to make is now removed — the field exists but is no longer consumed.

Risk: API confusion for future contributors. Minor correctness concern: if a future contributor sees fallbackExcludePaths and re-introduces sequential fallback expecting the paths to be pre-populated, they would work correctly — but the name is actively misleading.

Fix: Rename to quarantinedPaths or excludePaths to match the current semantics.

Blocks merge: No.

F4 — LOW | worker-pool.ts:892 | Circuit breaker and respawn-budget checks interact in a potentially surprising order for small pools

Evidence: handleWorkerDeath checks consecutiveFailuresPerSlot[workerIndex] >= consecutiveFailureThreshold BEFORE checking respawnCount[workerIndex] > maxRespawnsPerSlot. For a 2-worker pool (threshold = max(3, 2) = 3, maxRespawnsPerSlot = 3): on the 3rd consecutive failure the breaker trips (3 >= 3), even though the slot still has one respawn available. This is correct but the breaker can trip a multi-slot pool based on a single slot's failures. The cumulative timeout path (give-up) also calls handleWorkerDeath via the IIFE, and the timeout-retry path increments consecutiveFailuresPerSlot directly but does NOT call handleWorkerDeath. This means chronically-timing-out slots accumulate failure counts that never trigger the circuit breaker threshold check — only the respawnCount > maxRespawnsPerSlot path drops them.

Risk: Monitoring inconsistency, not a correctness bug. The pool is always eventually bounded.

Blocks merge: No.

F5 — INFO | parse-impl.ts:526-528 | Cache suppression checks cumulative quarantine across ALL prior chunks, not just the current chunk

Evidence:

const quarantineSnapshot = workerPool?.getQuarantinedPaths?.() ?? [];
const quarantineSet = new Set(quarantineSnapshot);
const chunkHadQuarantine = chunkFiles.some((f) => quarantineSet.has(f.path));

The quarantine grows across all chunks. A file quarantined in chunk 1 would suppress caching for a later chunk IF that later chunk contained the same file. But since parseableScanned is sorted alphabetically and assigned to chunks in order, each file appears in exactly one chunk. So the cross-chunk suppression concern is moot: no file can appear in two different chunks in the same run.

Risk: None in practice. The logic is overly conservative but safe.

Blocks merge: No.

F6 — LOW | worker-pool.ts:1392 | exitHandler does not exempt exit code 0 from quarantine

Evidence: A worker exiting cleanly (code 0) is treated identically to a crash: the in-flight file is quarantined and the slot respawns. If a worker exits cleanly mid-job (e.g., due to an uncaught exception that set exit code 0 before dying), a valid file could be unnecessarily quarantined.

Risk: Low — a worker exiting with code 0 during active parsing is unusual. The pool's quarantine + respawn behavior bounds the blast radius. Noted in PR description as a P2 residual.

Blocks merge: No.

F7 — INFO | worker-pool.ts: dispatch non-reentrancy is documented but not enforced

Evidence: The code comment states: "Worker dispatch itself stays serial because WorkerPool.dispatch is not reentrant (concurrent calls would race on the shared per-slot busy/in-flight state)." Currently safe because parse-impl.ts awaits each dispatch sequentially. But there is no assertion, mutex, or assert(activeWorkers === 0) guard to prevent accidental concurrent invocation.

Risk: A future caller that adds a concurrent dispatch would silently corrupt busySlots across the two call closures. Not a production issue today.

Blocks merge: No — but a note in the WorkerPool.dispatch JSDoc would be appropriate.

6. Worker Pool Reviewer Assessment

Lifecycle: Auto-respawn (bounded by maxRespawnsPerSlot), circuit breaker (per-slot consecutive failures or all-slots-dropped), and terminate are all correctly implemented. The stopped flag prevents double-resolution.

Stale events: Slot-generation guards at every handler entry (if (slotGenerations[workerIndex] !== slotGen) return) are correct. Generation is bumped atomically with the worker swap in replaceWorker. A late event from the dead worker carrying the old generation short-circuits.

maybeDone safety: Jobs are pushed to jobs before activeWorkers is decremented in requeueRemainder (called before the decrement in recoverAndResume). The give-up IIFE first decrements activeWorkers, then calls requeueRemainder (synchronous, may or may not push). If queue is empty and activeWorkers === 0, maybeDone() correctly resolves with partial results (quarantined files intentionally absent). This is the correct behavior, not a premature resolution.

recoverAndResume double-call: Protected by settled flag and cleanup() listener removal. Error, exit, and messageerror handlers each have if (!settled) guards. No double-call possible.

activeWorkers accounting: Each runWorker increments once on start. Each death path (recoverAndResume, give-up IIFE, retry IIFE finally) decrements exactly once. No double-decrement found.

Startup crash detection: waitForWorkerReady with 5s timeout correctly bounds the case of a worker crashing before emitting ready. The initialReadyGate symmetrizes this check for the initial spawn pool.

messageerror handling: Correctly routed through recoverAndResume (not treated as a different code path). Distinguishable from protocol decode errors by the error class (ProtocolDecodeError vs. the deserialization error from V8).

Listeners: handler uses .on (needed for multiple progress/sub-batch-done messages per job). errorHandler, exitHandler, messageErrorHandler use .once. cleanup() calls worker.removeListener for all four. Confirmed no listener leaks.

terminate(): Sets terminated = true, terminates all workers with .catch(() => undefined), clears workers.length and activeSlots. Does not interact with a running dispatch — if called during dispatch, stopped was already set by circuit breaker or the outer finally block in parse-impl calls it after the dispatch promise has settled.

Observability: getStats() exposes activeSlots, droppedSlots, quarantined, poolBroken, terminated, slotGenerations. Surfaced in verbose log per chunk. Adequate.

Integration tests: worker-pool.test.ts uses real worker_threads. The PR adds 512 lines to this file covering process exit, error, all-slots-dropped, stale events (via generation), and cumulative timeout. This is real production coverage.

Verdict for this lane: Pass with minor caveats noted.

7. Thread Pool / Pipeline Concurrency Reviewer Assessment

Non-reentrant dispatch: WorkerPool.dispatch is non-reentrant. parse-impl.ts correctly uses a serial for loop with await processParsing(...). parseChunkConcurrency only prefetches file contents (calls readFileContents async) — it does NOT overlap dispatch calls. The comment confirming this is accurate. No concurrent dispatch risk in the current code.

Chunk ordering: File content promises are pre-fetched but await chunkContentPromises[chunkIdx]! in the loop body preserves sequential processing order. Deferred extraction (imports, heritage, calls) accumulates across all chunks and resolves at the end in fixed order. Graph outputs are deterministic regardless of how fast file reads complete.

Progress monotonicity: The parse phase occupies 20-70% (50 points), with deferred extraction at 70-95% (imports 70-75, heritage 75-80, routes 80-85, calls 85-95). Each stage advances the progress bar linearly. The edge case where totalParseable === 0 correctly jumps to 95 without going through the 20% announce. No non-monotonic progress paths found.

Memory: parseChunkConcurrency = 2 with default chunkByteBudget = 2MB means at most ~4MB of raw file content is in memory ahead of the current chunk. This is conservative. The cumulative deferred arrays (deferredWorkerCalls, deferredWorkerImports, etc.) hold data for ALL chunks until the end-of-loop pass, which is the prior behavior. For large repos this could be significant, but it's bounded by the total repo size and unchanged from before.

Cache correctness: Cache hits replay the stored ParseWorkerResult[] through mergeChunkResults. Cache writes are suppressed when any file in the chunk is in the quarantine set. A subsequent run with a new pool will reattempt the chunk. The invariant is preserved: no partial chunk result is ever cached.

workerPoolSize === 0: Correctly checked at pool creation (options?.workerPoolSize !== 0). Sequential path runs intact.

Env reads: resolveChunkByteBudget, parseChunkConcurrency, and resolveAutoPoolSize are all called at invocation time (not module-level). resolveWorkerPoolOptions reads process.env at call time. No stale module-level env captures.

Verdict for this lane: Pass.

8. IPC / Transfer-List Assessment

encodeMessage / decodeMessage: Binary frame (1-byte tag + 4-byte LE uint32 length + UTF-8 JSON). Tags 0x01-0x08 validated. Short buffer, unknown tag, truncated payload, and invalid JSON all throw ProtocolDecodeError. decodeMessage accepts both Buffer and bare Uint8Array via Buffer.from(view.buffer, view.byteOffset, view.byteLength) — zero-copy view, correct for non-zero-offset views.

Hybrid envelope/contents dispatch (buildDispatchMessage): TextEncoder.encode creates dedicated ArrayBuffer (not pool-backed). Envelope (encodeMessage output via Buffer.allocUnsafe) is NOT transferred — correct, since Buffer.allocUnsafe may be pool-backed. The worker's decodeIncomingMessage checks decoded.files.length !== contents.length and throws a typed error if they diverge — this routes through the outer try/catch → encodeMessage(Error, ...) → recoverAndResume on the pool side. The byteLength metadata field is carried in the envelope but not validated against the actual transferred buffer length. This is a minor correctness gap — a corrupted/partial transfer would silently decode to the full transferred buffer length rather than the declared byteLength. In practice, transferList transfers are atomic (either the entire buffer is transferred or the call throws), so this scenario cannot occur under normal operation. Not blocking.

After transfer: The transferred Uint8Array buffers' underlying ArrayBuffers are detached on the main thread after postMessage. The main thread does not hold references to these buffers after the buildDispatchMessage call returns. Safe.

FakeWorker in tests: Tests use POJO messages, and the pool's decodeIncomingWorkerMessage tolerates both encoded and POJO shapes. The worker-pool.test.ts uses real Worker threads for IPC correctness paths.

Verdict for this lane: Pass. The byteLength non-validation is minor and non-exploitable.

9. Quarantine / Cache Assessment

When a file is quarantined: It is absent from the graph for the current run. This is documented: "files identified as the in-flight file at the moment of a worker death." The absence IS observable: the worker log emits "Worker quarantine: N new file(s) skipped this chunk (path/to/file.ts)" and getStats().quarantined is non-zero. The verbose throughput log surfaces the count per chunk.

Exit code behavior: Analyze exits 0 when quarantine occurs but the pool does not trip. This is documented in the PR description (quarantine = degraded completion, not hard fail). Exit code is non-zero only if the pool circuit breaker trips. This behavior is deliberate and acceptable — the operator can see the quarantine log even on exit 0. Whether this should be a nonzero exit for "incomplete graph" is a product policy question beyond the scope of this PR.

Cache suppression: The logic at parse-impl.ts:525-546 correctly suppresses cache write if any file in the chunk is quarantined. On the next run, the chunk gets a miss and reattempts. The quarantine is session-scoped (new pool = fresh quarantine set), so the reattempt is clean.

Cross-chunk quarantine affecting cache: Not a practical issue — alphabetically-sorted chunks guarantee each file is in exactly one chunk. A quarantined file from chunk 1 cannot suppress caching for chunk 3. Confirmed safe.

Tests for this behavior: parse-impl-quarantine-cache-skip.test.ts is an integration test (398 lines) that exercises the quarantine + cache interaction end-to-end. It is real (not mock-only). This satisfies DoD §2.7.

Verdict for this lane: Pass.

10. TypeScript Capture Assessment

Semantic correctness: findSelfOrAncestorOfType[s] walks from the capture node's own subtree upward. For every anchor type used in the TS query:

• import_statement / export_statement: findSelfOrAncestorOfTypes(['import_statement', 'export_statement']) — if the query captures the statement node directly, self matches on first step. Falls back to findNodeAtRange if null.
• call_expression (dynamic imports, call arity): findSelfOrAncestorOfType('call_expression') from the anchor node. For @import.dynamic the anchor is the call_expression itself — self-match on first step. For @reference.call.*, the anchor is the callee name inside the call — the call_expression is the immediate parent. Correct.
• member_expression (read member): Self-match when anchor is the member_expression.
• function_declaration, method_definition etc. (arity): The @declaration.method/function anchor is the function name, with the function node as the immediate parent or ancestor. findFunctionNode handles this.
• Falls back to findNodeAtRange in all cases if the ancestor walk returns null. So no regression from the walk failing to find the node — only a performance regression back to the old behavior.

groupedNodes parallel map: As noted in PR residuals (P2), groupedNodes and grouped are populated in the same loop iteration and are always in sync. Not a correctness issue in the current code; cleanup is a future follow-up.

Tests: typescript-captures-anchor.test.ts adds exact-count assertions (toBe(1), toBe(2)) for all the anchor types the rewrite touches. DoD §2.7 compliance confirmed. The one unused helper (findMatch) is a cleanup item.

Performance claim: Verification by @magyargergo shows emitTsScopeCaptures on checker.ts took ~3.2s vs. >7min before. The root-DFS elimination is the correct fix for the pathological case.

Verdict for this lane: Pass with one minor cleanup item (unused findMatch).

11. Docs / Benchmark / Operator Experience Assessment

README.md / gitnexus/README.md: New env vars (GITNEXUS_WORKER_POOL_SIZE, GITNEXUS_WORKER_MAX_RESPAWNS_PER_SLOT, etc.) and --workers CLI flag are documented with correct defaults. The defaults in the docs match the constants in the code. No discrepancies found.

bench/parse-throughput.md: The doc structure, methodology, and harness recipe are well-written. However, the measurement table has TBD values and the doc explicitly states it should be filled in before merging. This is the primary documentation concern for this PR. The doc says it's a "scaffold" — so either ship it as clearly-labeled future work OR fill in the numbers.

Help text / CLI wiring: --workers <n> is a Commander option wired through AnalyzeOptions.workers → workerPoolSize → PipelineOptions. --workers 0 disables workers via the !== 0 check. --worker-timeout sets env and is snapshot/restored. --verbose is threaded as env. All options are consistent between help text and implementation.

Verbose log: Per-chunk throughput log (files/s, pool stats) emits under isDev || isVerboseIngestionEnabled(). Previously isDev-only, so operators couldn't see it with --verbose in production. Fixed in this PR. Correct.

Verdict for this lane: Minor concern on benchmark TBD values.

12. Hidden Unicode / Hygiene

Scan result: grep -nP "[\x{202A}-\x{202E}\x{2066}-\x{2069}\x{200B}\x{200C}\x{200D}\xEF\xBB\xBF]" on the flagged files returned no matches.

The non-ASCII characters GitHub rendered warnings for are em dashes (—) used in code comments, which are visible punctuation. Per the review instructions: "Do not block ordinary visible punctuation, Markdown em dashes, smart quotes, or emoji if repo style allows them." These are acceptable.

CodeQL findings: Two findings on typescript-captures-anchor.test.ts — unused findMatch (confirmed) and countMatchesTsx (NOT actually unused — called on line 88). CodeQL's second finding is a false positive.

Verdict: No blocking hidden Unicode. One real CodeQL finding (unused findMatch).

13. CI and Test Adequacy

CI status (latest run, from comment):

• Typecheck: ✅
• Tests: ✅ (9093 passed, 0 failed, 39 skipped)
• E2E: ✅

Skipped tests: The 39 skipped tests include "TypeScript large-file cache-miss parser buffer regression" and "C# large-file" suites. These appear to be pre-existing skips due to environment/grammar availability, not related to this PR's changes.

Test coverage for changed domains:

The worker-pool-resilience.test.ts uses FakeWorker (not real Worker threads). The worker-pool.test.ts integration test uses real threads and is the primary IPC/lifecycle coverage. This split is acceptable: resilience logic is unit-tested with controlled fake workers; IPC contract is tested with real threads.

Verdict: Test coverage is adequate for the changed domains. DoD §2.7 exact-count assertions are present in new tests.

14. Final Verdict

Production-ready with minor follow-ups.

The core fix is sound and well-engineered: pathological files are bounded by the cumulative timeout budget + quarantine, worker crashes are bounded by the respawn budget + circuit breaker, IPC transfer-list is correctly zero-copy with no pool-buffer transfer risk, cache suppression correctly blocks partial chunks from being persisted, and the TypeScript capture optimization correctly preserves semantic output while eliminating the per-match root DFS.

Required before merge:

1. Remove the [WIP] from the PR title.
2. Remove or call the unused findMatch function in typescript-captures-anchor.test.ts:28 (CodeQL F1).
3. Either fill in the benchmark measurement rows in bench/parse-throughput.md or remove the self-contradictory "fill in before merging" instruction from the doc (F2).

Non-blocking follow-ups (can be separate PRs):

• Rename WorkerPoolDispatchError.fallbackExcludePaths → quarantinedPaths or excludePaths (F3).
• Add a non-reentrancy assertion or JSDoc to WorkerPool.dispatch to document and guard the contract (F7).
• Consider adding byteLength validation in the hybrid envelope decode path.
• Address P2 residuals from the PR description: groupedNodes parallel map, Windows path separator, exit code 0 exemption.

Windows benchmark: full-root microsoft/TypeScript analyze (fixes #1684)

Verified on Windows that root gitnexus analyze on a fresh clone of microsoft/TypeScript completes successfully with this branch — no infinite hang on tests/cases/fourslash/reallyLargeFile.ts (~3.5 MB fourslash fixture).

Acceptance criteria (#1684)

Benchmark runs (same machine, same env)

All runs used:

$env:NODE_OPTIONS = "--max-old-space-size=24576"
$env:NODE_ENV = "development"          # required for 📊 throughput logs
$env:GITNEXUS_VERBOSE = "1"
$env:GITNEXUS_MAX_FILE_SIZE = "32768"
$env:GITNEXUS_WORKER_SUB_BATCH_TIMEOUT_MS = "600000"
$env:GITNEXUS_PARSE_CHUNK_CONCURRENCY = "4"

gitnexus analyze <TypeScript-root> --force --index-only --skip-agents-md --skip-skills \
  --max-file-size 32768 --worker-timeout 600 --workers 16 -v

Takeaway: Runs 2 and 4 produce effectively identical graphs (±1 node/edge). Run 4 is ~14 min slower end-to-end on this box; the important regression fix is completion without hang, not a large throughput win on TS-root.

Run 4 phase breakdown (6c6fc774)

Peak RSS during deferred parse: ~23 GB (24 GB heap cap). After ✓ Phase: parse, memory dropped to low GB and the run finished cleanly.

Quarantine evidence (Run 4)

Worker 0 parse job exhausted cumulative timeout budget … exhausted=["tests/cases/fourslash/reallyLargeFile.ts"]
Worker quarantine: 1 new file(s) skipped this chunk
📊 chunk 65/66: 1 files in 1801613ms … 1 quarantined

Chunk 66 completed with the file skipped; indexing continued through scope resolution and wrote meta.json.

Artifacts

• Index: TypeScript/.gitnexus/meta.json (indexedAt: 2026-05-20, stats.files: 79,123)
• Verbose log (Run 4): .tmp-analyze-ts-root-native-msg.log on the benchmark worktree

What this validates for the PR

1. Worker quarantine + skip timed-out files in sequential fallback — pathological files no longer wedge root analyze indefinitely.
2. IPC path (6c6fc774) — native structured clone + transferList completes the same full-root workload as the earlier successful run without OOM on a capped heap.
3. Graph quality — core compiler symbols (compiler/checker.ts) indexed; stats match prior successful run.

Happy to re-run on another Windows host or post meta.json excerpts if useful for review.